Не так давно мы писали о том, что вышло обновление клиента VMware ESXi Embedded Host Client, позволяющего управлять хост-сервером ESXi через удобный веб-интерфейс. Сегодня мы поговорим о настройке клиента NTP на хосте, который необходим, чтобы виртуальные машины синхронизировали свое время с хостом через VMware Tools. Тулзы синхронизируют свое время при старте машин, операциях по созданию снапшотов (а значит и при создании бэкапов), vMotion и некоторых других событиях.

Если на хосте установлено неправильное время, то это может привести к проблемам при логине, а также невозможности старта службы vpxd на сервере vCenter Server Appliance (vCSA).

Давайте запустим ESXi Host Client по ссылке:

https://<esxi_ip_or_hostname>/UI

Далее нужно пойти в Manage > System > Time and Date, где нажать Edit settings:

Появится диалог настройки синхронизации времени хоста средствами службы NTP (ESXi NTP Client).

В поле NTP Servers нужно указать адрес сервера времени, а в поле NTP service startup policy есть 3 варианта:

• Start and stop with port usage - если выставлена эта опция, то службы NTP будут запускаться автоматически при доступности порта NTP (UDP Port 123) и отключаться, если он недоступен (например, применен Security Profile для сетевого экрана, который выключает доступ по этому порту). VMware рекомендует использовать эту настройку по умолчанию.
• Start and stop with host - включает и отключает службы NTP при загрузке хоста ESXi или перед его выключением.
• Start and stop manually - ручное управление службами NTP с точки зрения старта и остановки.

После того, как вы настроили политику NTP-клиента, он сам еще не запустится - его нужно запустить вручную из меню Actions:

Если же вы используете для настройки времени на хосте ESXi клиент vSphere Web Client, то они находятся в разделе Configure > System > Time configuration для выбранного хоста ESXi:

Далеко не все пользователи продуктов VMware и платформы vSphere в частности знают, что есть такое средство, как VMware Skyline. Это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов VMware vSphere (включая vSAN 6.6 и более поздние версии) и VMware NSX (поддержка других продуктов ожидается).

С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).

Также инженеры техподдержки VMware в рамках решения проблем заказчиков могут видеть весь их Inventory, а также все их обращения в техническую поддержку (Support Requests, SRs). Все это позволяет службам Global Support Services (GSS) быстро и эффективно решать проблемы заказчиков, а что более важно - предотвращать их.

По результатам анализа данных составляется сводный отчет (OSR), предоставляющий информацию о проблемах различной степени критичности:

Найденные проблемы можно отсортировать по степени критичности в веб-интерфейсе Skyline, а также отфильтровать по различным компонентам:

А вот так выглядят для вас и инженера TSE найденные проблемы в вашей инфраструктуре и возможные рекомендации по их устранению, которые вы можете с ним обсудить (обратите внимание, что для некоторых проблем даются ссылки на патчи ESXi их устраняющие):

В видео ниже можно посмотреть, как выглядит Skyline Operational Summary Report (OSR), получаемый в ходе работы :

Службы VMware Skyline доступны бесплатно пользователям Premier Services, а также тем, кто пользуется расширенным уровнем технической поддержки (Production Support). При этом в рамках Premier Services вам будут доступны рекомендации системных инженеров, их советы и дискуссии с ними, а в рамках Production Support все операции будут происходить через портал самообслуживания.

Для работы сервисов Skyline в вашей виртуальной инфраструктуре потребуется развернуть виртуальный модуль VMware Skyline Collector, который привязан к vCenter Server и/или NSX Manager. Он будет в автоматическом режиме собирать все необходимые данные в инфраструктуре VMware vSphere (а именно - конфигурации, доступные возможности и данные о производительности систем). Он также собирает информацию о происходящих изменениях и событиях, распознает паттерны определенных проблем, а также анализирует информацию с помощью как жестких правил, так и гибких механизмов машинного обучения (machine learning).

На настройку виртуального модуля Skyline Collector потребуется около получаса, после чего он будет работать в полностью автоматическом режиме.

Надо отметить, что данные о виртуальной инфраструктуре будут передаваться в VMware, но они будут идти по надежно защищенному каналу и храниться в собственном защищенном хранилище VMware на территории США (VMware Analytics Cloud, VAC). Если у вас несколько площадок, то данные, собираемые с каждой из них, будут агрегироваться и храниться централизованно. Помните, что сервис Skyline хранит такую чувствительную информацию, как имена хостов и IP-адреса.

Надо отметить, что для продукта vSAN часть сервиса Skyline доступна обычным пользователям. Это решение vSAN Support Insight, которое позволяет всем пользователям, участвующим в программе CEIP (Customer Experience Improvement Program), получить доступ к расширенной аналитике vSAN (даже без подключенного сервиса Skyline):

Так выглядит консоль vSAN Support Insight:

Если у вас появился интерес к сервису VMware Skyline, и у вас есть активный контракт Premier Services или Production Support, вы можете узнать больше и подписаться на него по этой ссылке - Managed Access Program.

Также у VMware Skyline есть своя страница сообществ - Skyline Community. К сожалению, пока службы VMware Skyline доступны для пользователей Premier Services в Северной Америке, Австралии, Индии, Новой Зеландии и Сингапуре, а для пользователей Production Support это возможно только в Северной Америке.

В ближайшем будущем эта география будет расширена: в середине 2018 года будут подключены пользователи Premier Services регионов EMEA и APJ/ANZ (в этих же регионах для Production Support приглашения будут в конце 2018 - начале 2019), а также все пользователи Северной и Южной Америки.

Вчера мы писали о том, что компания VMware выпустила документ, посвященный производительности последней версии платформы -  What’s New in Performance - VMware vSphere 6.7. Между тем, на днях также стал доступен и документ, рассказывающий обо всех новых возможностях продукта - What's New in vSphere 6.7.

В целом, обо всем этом мы писали в различных статьях про VMware vSphere 6.7, которые собраны здесь, но почитать whitepaper все равно будет не лишним, так как там есть несколько интересных деталей. Например, хорошая визуализация позиционирования памяти Persistent Memory:

Основные разделы документа:

• vCenter Server 6.7
• vSphere 6.7 Lifecycle Management
• vSphere with Operations Management 6.7
• vSphere 6.7 Developer and Automation Interfaces
• vSphere 6.7 Security
• vSphere 6.7 for Enterprise Applications
• Remote Directory Memory Access

Скачать док What's New in vSphere 6.7 можно по этой ссылке. Также вам может оказаться страница со всеми техническими ресурсами о новой версии платформы - vSphere 6.7 Technical Assets.

Компания VMware на днях выпустила новый документ, раскрывающий основные моменты улучшения производительности VMware vSphere 6.7 по сравнению с прошлой версией - What’s New in Performance - VMware vSphere 6.7.

В документе рассматриваются несколько основных улучшений, которые были сделаны в платформе:

• Увеличение в 2 раза числа операций vCenter в секунду по сравнению с vCenter 6.5.
• vCenter использует в 3 раза меньше памяти для основного процесса vpxd.
• Уменьшение времени на операции, связанных с DRS, до 3 раз (например, запуск виртуальной машины).
• Улучшение производительности Virtualization Based Security.

Здесь повышение производительности в числе транзакций в минуту составило 33% по сравнению с работой VBS в vSphere 6.5:

• Поддержка больших страниц памяти (Large Memory Pages) размером 1 ГБ.

Хост ESXi с размером страницы в 1 ГБ (появилось в vSphere 6.7) работает на 26% лучше, чем хост со страницей в 2 МБ:

• Улучшения драйвера vmxnet3 версии 4 в плане механизмов RSS (улучшение 28-146% в числе полученных пакетов в секунду) и VXLAN/Geneve Offload (до 415% улучшение в пропускной способности канала при некоторых условиях).
• Поддержка новых сервисов Persistent Memory.

С помощью технологии vSphere Persistent Memory пользователи могут применять специальные аппаратные модули от Dell-EMC и HPE (DRAM NVDIMM), которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory.

Работает это быстрее, чем SSD (vPMEMDisk - это работа такой памяти как локальное хранилище хоста ESXi, а vPMEM - прямое предоставление хранилища гостевой системе как устройства):

• Скорость создания мгновенных клонов (Instant Clones) виртуальных машин по сравнению со скоростью создания связанных клонов.

Мгновенные клоны создаются почти в три раза быстрее, чем связанные (время в секундах на создание 64 клонов):

Все остальное - в документе "What’s New in Performance - VMware vSphere 6.7".

7 лет назад мы писали про утилиту ESXi-Customizer, которая позволяет добавлять кастомные драйвера в ISO-образ VMware ESXi. У того же автора (Andreas Peetz) есть еще одна замечательная утилита, которая актуальна и на сегодняшний день - ESXi-Customizer-PS. Актуальна - это значит, что ее последняя версия (от 18 апреля этого года) поддерживает последние версии платформ и фреймворка - vSphere 6.7 и PowerCLI 10.

ESXi-Customizer-PS - это PowerShell-скрипт, который на входе принимает большое число различных параметров, а на выходе дает кастомизированный ISO-образ или офлайн-бандл ESXi:

Сценарий имеет три режима работы:

• Создать установочный образ ISO или Offline Bundle напрямую из хранилища VMware Online depot (стандартный режим).
• Создать установочный образ ISO или Offline Bundle из скачанного ESXi Offline Bundle (параметр -izip).
• Обновление локального ESXi Offline Bundle с помощью ESXi patch bundle из хранилища VMware Online depot (параметры -izip -update).

С помощью этих трех режимов вы можете добавлять бандлы из хранилища V-Front Online Depot, либо любого другого Online Depot, указав его URL, а также можно указывать локальные Offline Bundles и VIB-файлы (собственно, кастомные драйверы или кастомный софт под ESXi).

Об использовании утилиты ESXi-Customizer-PS Alex Lopez снял хороший видеотуториал:

Скрипт можно использовать множеством способов. Давайте рассмотрим основные:

1. Вызов скрипта без параметров.

Например:

.\ESXi-Customizer-PS-v2.6.0.ps1

В этом случае утилита создаст ISO-образ ESXi самой последней версии (6.7 на данный момент) и с самым последним уровнем обновлений. Вы также можете указать конкретный номер версии ESXi, для которой будет получен ISO с последними обновлениями. Например:

• -v50 : ESXi 5.0 ISO
• -v51 : ESXi 5.1 ISO
• -v55 : ESXi 5.5 ISO
• -v60 : ESXi 6.0 ISO
• -v65 : ESXi 6.5 ISO
• -v67 : ESXi 6.7 ISO

Также есть еще три параметра:

• -outDir : записывать ISO-образ в указанную директорию.
• -sip : не использует последний уровень патчей, а показывает меню, где можно выбрать конкретный патч. Новые патчи будут показаны сверху. Также будут показаны и профили, которые содержат только обновления безопасности и/или VMware Tools.
• -ozip : на выходе будет сформирован не ISO, а ESXi Offline Bundle, который можно импортировать в Update Manager, указать вручную для обновления черезesxcli или использовать как входной бандл для следующих кастомизаций.

2. Использование офлайн бандла ESXi Offline Bundle как входного параметра (вместо VMware Online depot).

Например, такая команда позволит вам получить ISO-образ из офлайн-бандла:

.\ESXi-Customizer-PS-v2.6.0.ps1 -izip .\VMware-ESXi-6.0.0-2494585-depot.zip

Офлайн бандл можно скачать через VMware Patch Download portal. Некоторые вендоры также предлагают свои кастомизированные офлайн-бандлы, например HP. Офлайн бандлы VMware можно найти вот тут. Также вы можете использовать параметры из пункта 1.

3. Добавление дополнительных пакетов из присоединенных хранилищ Online depots.

Например, вот эта команда позволит добавить сетевые драйверы, отсутствующие в образе ESXi 5.5:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v55 -load net-r8168,net-r8169,net-sky2

Данные драйверы есть в VMware Online depot, так как они есть в составе ESXi 5.0 и 5.1, но были исключены из дистрибутива ESXi 5.5. Важно, что для ESXi 6.0 такая штука для этих драйверов уже не прокатит, так как они были добавлены в черный список (blacklised).

4. Присоединение онлайн-хранилища V-Front Online Depot и других хранилищ.

Делается это следующей командой:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v60 -vft -load sata-xahci,net55-r8168

В результате в образ ESXi 6.0 будут добавлены драйверы из V-Front Online Depot (sata-xahci и net55-r8168).

5. Добавление локальных офлайн-бандлов и VIB-файлов.

Вот такая команда добавит все офлайн-бандлы и VIB-пакеты в последний образ ESXi 6.7:

.\ESXi-Customizer-PS-v2.6.0.ps1 -pkgDir C:\temp\pkg

Этой командой вы сможете добавить драйверы типа 3rd party или community supported.

6. Обновление локальных офлайн-бандлов.

Вот такая команда обновит ESXi 6.0 Offline bundle последними патчами из онлайн-хранилища VMware:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v60 -izip .\VMware-ESXi-6.0.0-2494585-HP-600.9.1.39-Mar2015-depot.zip -update

Здесь надо не забывать указывать номер версии патчируемого гипервизора (в данном случае -v60 - это ESXi 6.0).

7. Расширенные параметры.

У утилиты есть еще несколько расширенных параметров, которые дают еще больше возможностей по кастомизации образов ESXi:

• -log : указание пути к кастомному лог-файлу.
• -test : тестирование возможности построения или обновления образа без накатывания реальных изменений. Экономит массу времени, так как не перестраивает ISO или zip, а также не качает обновления и образы из VMware Online depot.
• -nsc : это опция -noSignatureCheck, которая отключает проверку сигнатуры при выполнении функции экспорта. Ее нужно использовать, если вы получаете ошибку типа "Could not find trusted signer." (пакет с некорректными или отсутствующими сигнатурами).
• -ipname, -ipdesc, -ipvendor: задание собственных атрибутов в профиле образа. По умолчанию в имени и описании останутся прежние значения с приставкой "customized", а имя вендора не изменится.
• -remove vib1[,...]: удаление одного или нескольких VIB-пакетов из кастомного образа.

Скачать ESXi-Customizer-PS-v2.6.0.ps1 можно по этой ссылке.

Мы иногда пишем о том, что большие обновления как хост-серверов VMware ESXi, так и управляющих компонентов VMware vCenter / vCenter Server Appliance всегда лучше ставить заново, а не делать апгрейд с предыдущих версий (если у вас, конечно, есть такая возможность). Да, вы не сохраните логи и исторические данные, но это позволит вам избежать различных проблем, связанных с устаревшими компонентами, которые останутся при обновлении и могут вступить в конфликт с новыми функциями при определенных обстоятельствах.

Такой вот пример приводит и Mike Foley в статье про механизм безопасной загрузки хостов vSphere Secure Boot. Когда он обновил свою инфраструктуру на VMware vSphere 6.7 с версии 6.5, он решил проверить функции Secure Boot и возможности модуля TPM 2.0.

Но когда он включил эти возможности в UEFI BIOS, он получил "розовый экран смерти" (PSOD) сервера ESXi:

Причина оказалась проста - для некоторых legacy-драйверов при обновлении не были обновлены их сигнатуры для VIB-пакетов, поэтому механизм Secure Boot не может эти сигнатуры проверить и выводит хост в PSOD при загрузке.

Чтобы найти эти драйверы, он запустил скрипт secureBoot.py, который показывает модули, препятствующие безопасной загрузке:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

Вывод оказался примерно таким:

[root@esxi-117] /usr/lib/vmware/secureboot/bin/secureBoot.py -c Secure boot CANNOT be enabled: 

Failed to verify signatures of the following vib(s): [

net-tg3 

dell-configuration-vib 

net-i40e 

net-igb 

net-ixgbe 

vmware-esx-perccli-1.05.08 

ima-qla4xxx 

misc-cnic-register 

net-bnx2 

net-bnx2x 

net-cnic 

net-qlcnic 

net-qlge 

scsi-bnx2fc 

scsi-bnx2i 

scsi-qla4xxx 

scsi-megaraid-sas 

lsu-lsi-mptsas-plugin].

All tardisks validated. All acceptance levels validated

Посмотрев на каждый драйвер по отдельности, он понял, что все это старые Linux-драйверы, которые были заменены в новых версиях VMware vSphere своими Native-аналогами. Например, для драйвера net-tg3 есть аналогичный нативный драйвер ntg3, а для net-bnx2i есть bnxnet.

Поэтому далее Майк просто удалил все VIB-пакеты со старыми драйверами следующей командой:

esxcli software vib remove -n scsi-megaraid-sas

esxcli software vib remove -n net-tg3

esxcli software vib remove -n net-i40e

esxcli software vib remove -n net-igb

esxcli software vib remove -n net-ixgbe

esxcli software vib remove -n net-qlcnic

esxcli software vib remove -n scsi-bnx2i

esxcli software vib remove -n scsi-bnx2fc

esxcli software vib remove -n net-bnx2x

esxcli software vib remove -n scsi-qla4xxx

esxcli software vib remove -n net-cnic

esxcli software vib remove -n net-bnx2

esxcli software vib remove -n net-qlge

esxcli software vib remove -n misc-cnic-register

esxcli software vib remove -n lsu-lsi-mptsas-plugin

esxcli software vib remove -n ima-qla4xxx

esxcli software vib remove -n vmware-esx-perccli-1.05.08

esxcli software vib remove -n dell-configuration-vib

В итоге его хост смог безопасно загрузиться через Secure Boot. Также Майк далее в статье рассматривает решение еще одной специфической проблемы, которая встречается довольно редко.

Ну а мы еще раз напомним - если есть возможность поставить новую мажорную версию ESXi с нуля - лучше скачайте ISO-образ и сделайте это, вместо того, чтобы "быстро и безопасно" обновиться на новую версию.

На сайте проекта kauteetech.github.io есть интересный калькулятор vSAN Effective Capacity для показа распределения емкости отказоустойчивых хранилищ VMware vSAN. Он показывает размещение различных областей данных в общем пространстве хранения, организованных на серверных узлах All-flash (все SSD диски) или гибридной модели (SSD для кэша, HDD для данных):

Это очень простая утилита для самой примерной визуализации расчетов. Напомним, что для точного вычисления всех параметров есть VMware vSAN Sizer (он также умеет рассчитывать необходимое число узлов vSAN).

В качестве исходных параметров для vSAN Effective Capacity могут быть использованы:

• Число узлов кластера (хостов ESXi)
• Число дисковых групп
• Соотношение дисков с данными на группу
• Запас по емкости кластера в процентах
• Затраты на хранение контрольных сумм RAID
• Размер диска с данными
• Тип обеспечения отказоустойчивости FTT (число избыточных копий данных)

Штука интересная, поскольку кроме численных параметров сырой и эффективной емкости, наглядно показывает, сколько от общего объема хранилищ занимает сегмент с данными в определенной конфигурации.

Еще в далеком 2011 году мы писали о средстве VMware I/O Analyzer, которое позволяет сгенерировать нагрузку на хранилища VMware vSphere, а после чего замерить производительность этих хранилищ. Делается это средствами интегрированного фреймворка, который поддерживает распределенную архитектуру - центральный управляющий виртуальный модуль и воркеры (генераторы нагрузки).

В 2014 году это средство еще раз обновилось для поддержки актуальных на тот момент версий ESXi, ну а на днях появилось обновление VMware I/O Analyzer 1.6.2u1, которое поддерживает VMware vSphere 6.5 и более поздние версии, то есть vSphere 6.7.

Напомним основные возможности VMware I/O Analyzer:

• Интегрированный фрейворк для тестирования производительности хранилищ.
• Простая настройка и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
• Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
• Возможность экспорта данных для последующего анализа.
• Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
• Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
• Графическая визуализация метрик и результатов анализа производительности.

В новой версии I/O Analyzer 1.6.2u1 появились следующие фичи:

• Поддержка последних версий vSphere.
• Обновление протокола до версии OpenSSL 1.0.2o.
• Сценарий для горячего обновления с прошлой версии 1.6.2.
• В прошлой версии 1.6.2 были пофикшены уязвимости Shellshock и Heartbleed.

Скачать VMware I/O Analyzer 1.6.2u1 можно по этой ссылке. Инструкция к данному средству тестирования доступна тут.

Давненько ничего нового не было на сайте проекта VMware Labs. А вот на днях компания VMware выпустила полезную утилиту ESXi Compatibility Checker, представляющую собой Python-скрипт, проверяющий аппаратные компоненты хост-серверов на совместимость с платформой VMware vSphere и ее различными версиями.

Эта утилита может быть использована при замене различных компонентов хостов ESXi, а также обновлении серверов vCenter/ESXi. В целом, такую информацию можно собрать и вручную с помощью различных команд и в графическом интерфейсе, но у сервера так много системных девайсов, устройств ввода-вывода и прочего, что скрипт весьма и весьма упрощает эту задачу.

Результаты работы сценария ESXi Compatibility Checker можно вывести в xls-отчет, который потом можно использовать для планирования обновлений и обсуждения.

Кроме того, можно проверить хосты на возможность апгрейда на какой-нибудь релиз ESXi и соответствие аппаратным требованиям какой-либо версии, например:

Host 10.143.XX.XX> upto 6.5.0 -s
        [OK] The specified release (VMware vSphere Hypervisor (ESXi) 6.5.0) is upgradable from this VMware vSphere Hypervisor (ESXi) 6.0.0
        [Server: Warnings]  Server 'PowerEdge R720' may not be compatible for ESX 6.5.0
        [IO: Warnings]  Some IO devices may not be compatible for ESX 6.5.0
        Compatibility issues:
        - Server Model 'PowerEdge R720' with Intel Xeon E5-2600-v2 Series (ID:33815) is certified
            but current CPU Series (features:0x206d7) is not supported
            Certified BIOS versions are higher than 2.1.2
            More information: http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=server&productid=33815
        - IO Device 'PERC H310 Mini' (PCIID:1000:0073:1028:1f51) is certified
            but current driver (megaraid_sas) is not supported
            More information: http://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=40344

Возможно, когда-нибудь эта функциональность станет частью vCenter. Скачать скрипт ESXi Compatibility Checker можно по этой ссылке.

На днях (уже почти неделю назад) компания VMware объявила о релизе второго пакета обновлений VMware vSphere 6.5 Update 2. Мы упустили этот момент и теперь восполняем пробел. Но зато можно сказать, что за прошедшую неделю никаких серьезных багов обнаружено не было, поэтому обновляться можно смело.

Но есть важный нюанс: прямой апгрейд с VMware vSphere 6.5 Update 2 на VMware vSphere 6.7 - не поддерживается! Если же вы будете обновляться с vSphere 5.5, то вам минимально потребуется Update 3b для старта процедуры апгрейда на 6.5 U2.

Посмотрим, что нового появилось в vSphere 6.5 Update 2:

1. Новое в vCenter Server 6.5 Update 2.

vCenter теперь поддерживает режим Enhanced Linked Mode (ELM) при развертывании с Embedded Platform Service Controller (PSC):

Такая конфигурация поддерживает до 15 серверов vCenter режиме ELM, при этом она может быть создана только с нуля, а не в результате апгрейда предыдущих версий vCenter.

Также vCenter 6.5 U2 получил следующие новые возможности:

• Windows vCenter Server с кастомными портами HTTP/HTTPS теперь поддерживается при миграции на vCenter Server Appliance.
• С помощью утилиты TLS Configuration можно настроить SSL-туннели на порту 8089.
• Возможность резервного копирования и восстановления в режиме Embedded Linked Mode с репликацией deployment topology API.
• vMotion и холодная миграция ВМ между инфраструктурами vCenter Server версии 6.0 Update 3 и более поздних, кроме того поддерживается и миграция в среду VMware Cloud on AWS.

2. Обновления платформы и серверов ESXi.

Здесь можно отметить следующие улучшения:

• Поддержка IPv6 для Key Management Server (KMS) при шифровании виртуальных машин средствами VM Encryption.
• Дополнительные алармы об устаревании сертификатов KMS, отсутствующих хостах и ключах виртуальных машин.
• Кастомизация дефолтных портов службы HTTP Reverse Proxy в графическом интерфейсе и через CLI при развертывании vCenter Server Appliance.
• Управление несколькими пространствами имен совместимыми со спецификациями Non-Volatile Memory Express (NVMe) 1.2, а также улучшенный диагностический лог.
• Добавления тэгов к модулю Trusted Platform Module (TPM) версии 1.2 на серверах ESXi через интерфейс ESXCLI.
• Поддержка нативных драйверов контроллеров roadcom SAS 3.5 IT/IR в комбинациях дисковых устройств NVMe, SAS и SATA.
• Поддержка драйверов Microsemi Smart PQI (smartpqi) для контроллеров HPE ProLiant Gen10 Smart Array Controller.
• Отдельные драйвера адаптеров LightPulse и OneConnect.

Остальные улучшения и нововведения можно почитать в VMware ESXi 6.5 Update 2 Release Notes и VMware vCenter 6.5 Update 2 Release Notes. Скачать VMware vSphere 6.5 Update 2 можно по этой ссылке.

В начале марта этого года мы писали о большом релизе VMware PowerCLI 10.0, в котором основной фичей была поддержка работы фреймворка в ОС Linux и Mac OS (см. постер на эту тему). Одновременно с выпуском новой версии платформы VMware vSphere 6.7 обновился и PowerCLI до версии 10.1.

Вот какие основные нововведения появились в PowerCLI 10.1:

• Полная поддержка VMware vSphere 6.7
• Поддержка решения NSX-T 2.1
• Новый модуль VMware.Vim
• Новые командлеты для управления бандлами сценариев Auto Deploy

Модуль VMware.Vim - это двадцатый модуль PowerCLI, который дает доступ к последним API платформы, включая те, что используются для управления облачной инфраструктурой VMware Cloud on AWS.

Для Auto Deploy появилось два новых командлета:

• Set-ScriptBundleAssociation - позволяет ассоциировать хост ESXi с определенным бандлом сценариев.
• Remove-ScriptBundle - соответственно, удаление бандла сценариев.

Напомним, что начиная с версии 10.0, фреймворк PowerCLI не дает возможность работать с недействительным сертификатом. Чтобы разрешить это, надо выполнить команду:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

Обновление на PowerCLI 10.1 выполняется одной командой:

Update-Module -Name VMware.PowerCLI

Ссылки, которые вам будут полезны при работе с PowerCLI 10.1:

• VMware PowerCLI Change Log
• VMware PowerCLI 10.1.0 User’s Guide
• VMware PowerCLI 10.1.0 Cmdlet Reference

Мы много писали о релизе новой версии платформы виртуализации VMware vSphere 6.7 и ее возможностях, а сегодня хотим рассказать про нововведения функции Instant Clone, о которых написал Дункан Эппинг. Напомним, что функция мгновенного клонирования виртуальной машины (ранее известная как VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere.

Делается это за счет того, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

Такая схема использования родительской ВМ в VMware vSphere 6.5 требовала, чтобы родительская машина и ее мгновенные клоны находились на одном сервере ESXi. А значит для этих ВМ не поддерживались такие технологии, как vMotion/HA/Storage vMotion и DRS. Между тем, это очень важно для служб тестирования, отделов DevOps и т.п.

Теперь же в VMware vSphere 6.7 появились следующие улучшения Instant Clone:

• Появился простейший публичный API, который позволяет автоматизировать процесс создания и перемещения мгновенных клонов. Он умеет пока не все, но будет развиваться. GUI для этого пока также нет.
• Интеграция с технологиями vSphere для обеспечения доступности виртуальных машин (HA, DRS, vMotion, Storage / XvMotion и т.п.).
• Поддержка двух рабочих процессов создания мгновенных клонов: первый - это последовательное создание клонов в процессе работы родительской виртуальной машины, второй - отпочковывание клонов от "замороженной" родительской ВМ.
• Использование технологии P-Share для дедупликации страниц памяти средствами технологии Transparent Page Sharing (даже когда она отключена на хосте ESXi).
• Теперь отношение родитель-клон не такое тесно связанное, как раньше.

Давайте посмотрим на первый рабочий процесс - создание мгновенных клонов работающей ВМ. Это, например, может пригодиться, когда вы массово тестируете обновление компонентов какого-либо приложения. Обновили первый компонент - сделали несколько клонов для тесткейсов, провели тесты, потом обновили следующий - и снова сделали несколько клонов для тестирования.

Схематично это выглядит вот так:

У родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее. Пока для этого нет визуального интерфейса, но все это можно потестировать через MOB-браузер.

Такая схема имеет недостаток в том, что у родительской ВМ плодятся дельта-диски, что приводит к тому, что быстродействие родительской ВМ замедляется, а сама структура за счет увеличения числа дисков существенно усложняется, что потенциально может привести к различного рода сбоям.

Также в данном случае есть проблема сетевой идентификации - все виртуальные машины, которые рождаются как мгновенные клоны имеют те же настройки IP и MAC-адреса, что и родитель. Чтобы изменить их потребуется выполнить следующие действия:

1. После создания Instant Clone внутри нужно отключить сетевой интерфейс через свойство VirtualEthernetCard->connectable->migrateConnect, устанавливаемое в значение disconnect. Далее нужно задать настройки сетевой идентификации ВМ.
2. Если не хочется менять параметры сетевой идентификации, новые ВМ можно просто запускать в отдельной портгруппе, без выхода во внешнюю сеть во избежание конфликтов IP и MAC-адресов.
3. Внутри мгновенного клона нужно обновить настройки сетевого интерфейса, чтобы гостевая ОС получила новый MAC-адрес. Это можно автоматизировать через Guest Operations API.
4. Снова присоединить виртуальную сетевую карту к ВМ, чтобы новые настройки были применены и машина свободно работала в сети. Для этого нужно установить значение свойства VirtualEthernetCard->connectable->connected в true.

Вторая схема - это "заморозка" родительской ВМ таким образом, что ее CPU перестает исполнять инструкции (для этого используется функция instantclone.freeze в утилите vmware-rpctool). После этого механизм Instant Clone способен создавать связанные клоны этой подмороженной ВМ.

Это позволяет не плодить дельта-диски родительской ВМ (так как ее состояние не изменяется) и достичь унифицированной конфигурации мгновенных клонов:

Такая схема может подойти для масштабирования каких-либо типовых унифицированных нагрузок в виртуальных машинах - например, VDI, хосты с контейнерами, Hadoop-воркеры и так далее.

Поморозка ВМ происходит средствами утилиты vmware-rpctool, которая развертывается в виртуальной машине вместе с VMware Tools.

Также теперь мгновенные клоны существенно меньше привязаны к родительской ВМ, что позволяет использовать их более широко, а сами они называются "parentless".

Ну и напоследок обзорное видео от Дункана, посвященное использованию Instant Clones в платформе VMware vSphere 6.7:

Кроме этого, советуем также почитать вот эту статью Вильяма Лама, посвященную мгновенным клонам.

Как все уже знают, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Напомним наши статьи о нововведениях этого решения:

• Новая версия платформы виртуализации VMware vSphere 6.7 доступна для скачивания
• Сравнение максимумов конфигурации VMware vSphere 6.5 и 6.7
• Новые возможности VMware vCenter 6.7 - развертывание vCSA стало опцией по умолчанию
• Как отреагировали вендоры решений резервного копирования виртуальных машин на релиз VMware vSphere 6.7
• Новые возможности VMware vSAN 6.7 в составе vSphere 6.7
• Обновленный VMware Update Manager в vSphere Client 6.7
• Рекомендации по обновлению на VMware vSphere 6.7

Ну а сегодня мы расскажем еще об одной возможности vSphere в плане безопасности - поддержке технологии Virtualization Based Security (VBS) операционных систем Microsoft. Механизм VBS позволяет превратить сервер или рабочую станцию на базе ОС Windows Server 2016 или Windows 10 в защищенные системы, исполняющиеся в рамках гипервизора Windows, при этом некоторые компоненты выносятся за пределы гостевой системы. Например, за рамки ОС выносится система управления хэшированными парами логин/пароль (креденшены), называющаяся Credential Guard.

Как мы видим на картинке, гипервизор обеспечивает виртуализацию гостевой системы на сервере или ноутбуке, а также канал обмена между внешними компонентами (Credential Guard, Device Guard) и ОС. Такая архитектура обеспечивает большие трудности при доступе злоумышленников к областям памяти, где хранятся хэши паролей различных пользователей - ведь эта область вынесена за пределы операционной системы.

Также аппаратное обеспечение компьютера должно иметь в своем составе модуль TPM 2.0 (Trusted Platform Module), который обеспечивает механику безопасной загрузки (Secure Boot). Ведь если не использовать механизм безопасной загрузки, то атаку можно провести на сам гипервизор, подменив его компоненты, а дальше уже иметь доступ к основной виртуальной машине и остальным компонентам гипервизора, в том числе хранилищу паролей. Таким образом, для полной защиты нужно использовать связку VBS+TPM 2.0 (вторая версия TPM поставляется уже со всем современным оборудованием).

Чтобы такая схема работала, нужно обеспечить выполнение следующих требований:

• UEFI firmware (не BIOS).
• Опция безопасной загрузки Secure Boot с поддержкой TPM.
• Поддержка технологии Hardware virtualization (опция процессоров Intel VT/AMD-V) и функций IOMMU.

И самое главное - ОС Windows должна быть установлена со всеми этими включенными опциями, иначе потом настраивать VBS будет проблематично.

В случае с гипервизором ESXi для незащищенной виртуальной машины Windows все выглядит вот таким образом:

Чтобы защитить машину с помощью VBS, потребуется использовать вложенную (nested) виртуализацию - ведь гипервизор Windows Hypervisor надо запустить на платформе VMware ESXi. Для этого в настройках виртуальной машины надо выставить опцию Enable для пункта Virtualization Based Security:

Это позволит открыть все необходимые опции процессора для гостевой ОС виртуальной машины, в которой также будет работать гипервизор.

Выглядеть это будет следующим образом:

Чтобы эта схема работала, нужно выполнить 2 условия:

• Виртуальная машина должна иметь виртуальное железо Virtual Hardware версии 14, которое появилось в vSphere 6.7.
• Гостевую ОС виртуальной машины надо развертывать на базе UEFI и с уже включенной опцией Secure Boot (обратите внимание на эту опцию на панели Boot Options в разделе VM Options (см. скриншот настроек выше).

Ну и последняя деталь - это модуль TPM. Для физических систем этот модуль делается с расчетом на одну систему, имеет небольшой объем памяти защищенного хранилища (измеряется в килобайтах) и работает весьма медленно, так как это serial device.

Поэтому VMware сделала виртуальное устройство - vTPM 2.0, которое в качестве хранилища использует обычный файл .nvram. Физический TPM не рассчитан на то, чтобы поддерживать сотни виртуальных машин на одном сервере (просто не хватит объема хранилища и быстродействия), а виртуальный vTPM отлично справляется с этой задачей. К тому же, виртуальную машину с виртуальным vTPM можно переносить между серверами с помощью vMotion и делать ее резервные копии.

Но, само собой, файл nvram надо хорошо зашифровать, поэтому для виртуальной машины нужно включить VM Encryption. Это обеспечит работоспособность машины в защищенной среде совместно с опцией VBS. При этом диски ВМ шифрованными не будут, что позволит получить доступ к данным на уровне VMDK дисков в случае утери ключей.

Самое интересное, что vTPM 2.0 не требуется как-то отдельно устанавливать и настраивать - он автоматически обнаруживается средствами Windows со стандартными драйверами:

Утилита Device Guard and Credential Guard hardware readiness tool от компании Microsoft определяет этот vTPM, как совместимый, поэтому можете использовать его для виртуальных машин, к которым предъявляются повышенные требования к безопасности.

Недавно мы писали о новых возможностях HTML5-клиента для VMware vSphere 6.7. Он уже содержит в себе интерфейсы VMware vSAN и Update Manager, что делает его уже почти готовым к полноценной эксплуатации в производственной среде.

Но помимо vSphere Client, в инфраструктуре vSphere есть и ESXi Host Client, который позволяет управлять отдельными хост-серверами ESXi через веб-интерфейс.

Посмотрите полезный обзор новых фичей ESXi Host Client 6.7 от Virtualization24x7:

Как вы знаете, за прошедшие несколько недель состоялось несколько больших релизов от VMware, вышли обновления как самой платформы виртуализации VMware vSphere 6.7, так и апдейты продуктов VMware Site Recovery Manager 8.1, vRealize Operations 6.7 и других.

Вот суммарно что нового появилось в vSphere 6.7, если постараться уместить это на одну картинку:

Поэтому для многих пользователей VMware vSphere 6.5/6.0/5.5 пришло время большого апгрейда, особенно учитывая, что 19 сентября этого года заканчивается поддержка vSphere 5.5.

Правда не надо забывать, что системы резервного копирования еще не поддерживают vSphere 6.7, но, я думаю, эта ситуация исправится в самом ближайшем будущем. Ну и помните, что напрямую обновиться с vSphere 5.5 на 6.7 не получится, придется делать промежуточный апгрейд на 6.0/6.7:

Поддерживаемые пути апгрейда на vSphere 6.7 включают в себя следующие способы:

• Установщик ESXi
• Интерфейс ESXCLI
• Решение vSphere Update Manager (VUM)
• Механизм Auto Deploy

VMware написала в своем блоге интересный пост с рекомендациями по обновлению на vSphere 6.7, приведем оттуда самые важные моменты.

1. Общие рекомендации по платформе vSphere.

• vSphere 6.0 - это минимальная версия для апгрейда на vSphere 6.7.
• vSphere 6.7 - это последний релиз, который требует ручного указания всех сайтов SSO.
• В vSphere 6.7 только TLS 1.2 включен по умолчанию, TLS 1.0 и TLS 1.1 по умолчанию отключены.
• Так как структура метаданных томов VMFS6 изменилась, чтобы поддерживать выравнивание по 4K блокам, вы не сможете сделать апгрейд датастора VMFS5 на VMFS6. Это так и осталось со времени vSphere 6.5 (смотрите KB 2147824).

2. Рекомендации по обновлению vCenter.

• Развертывание vCenter Server Appliance 6.7 (vCSA) является рекомендуемой конфигурацией.
• vCenter Server 6.7 for Windows - это последний релиз для платформы Windows, далее все будет только на базе виртуального модуля.
• vCenter Server 6.7 не поддерживает Host profiles с версией ниже 6.0 (см. KB52932).
• vCenter Server 6.7 поддерживает работу Enhanced Linked Mode с внедренным компонентом Embedded PSC. Но это поддерживается только для чистых установок, а не апгрейдов. Будьте внимательны!
• Если вы используете защиту сервера vCenter в платформе vSphere 6.5 (vCenter High Availability, VCHA), то нужно будет удалить всю конфигурацию VCHA перед проведением апгрейда.

3. Совместимость с другими продуктами VMware.

На момент написания статьи vSphere 6.7 не поддерживала работу со следующими решениями последних версий:

• VMware Horizon
• VMware NSX
• VMware Integrated OpenStack (VIO)
• VMware vSphere Integrated Containers (VIC)

Также отметим, что в этой версии vSphere больше нет продукта VMware vSphere Data Protection (VDP), об этом мы писали здесь. Также нотификацию об этом можно увидить на странице сайта VMware, посвященной VDP.

4. Рекомендации по оборудованию.

• vSphere 6.7 больше не поддерживает некоторые модели процессоров от AMD и Intel. Их список приведен вот тут, а проверить текущую совместимость можно по этой ссылке.
• Следующие CPU пока еще поддерживаются, но их поддержка может быть прекращена в следующей версии:
  • Intel Xeon E3-1200 (SNB-DT)
  • Intel Xeon E7-2800/4800/8800 (WSM-EX)
• Виртуальные машины, которые совместимы с ESX 3.x и всеми более поздними версиями (начиная с hardware version 4) поддерживаются хостами ESXi 6.7.
• Версия железа Hardware version 3 больше не поддерживается.
• VM hardware version теперь называется VM Compatibility. Помните, что сначала надо обновить ее на машине до последней версии перед использованием на платформе vSphere 6.7.

Ну а мы со своей стороны рекомендуем всегда делать свежую установку vSphere, если это возможно, а не делать апгрейд, чтобы накопившиеся в прошлом прошлом проблемы вы не унаследовали в новой инсталляции.

Как вы все уже знаете, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Помимо описания новых возможностей решения мы также останавливались на новых функциях VMware vCenrer 6.7, а сегодня расскажем о некоторых нововведениях тонкого клиента VMware vSphere Client 6.7, построенного на базе технологии HTML5.

Напомним, что vSphere Client не удалось добить до полной функциональности, поэтому VMware выпустила и финальный релиз vSphere Web Client 6.7 на базе технологии Flash. Но обещают, что функционал клиентов уже почти одинаковый. Одним из шагов на пути к этому стала поддержка основных рабочих процессов vSphere Update Manager (VUM) в HTML5-клиенте.

Надо начать с того, что интерфейс VUM был полностью переработан, а не просто скопирован с Web Client. Рабочие процессы стали проще и понятнее.

Кстати, обратите внимание на гифке выше, как удобно теперь стало искать обновления для хостов ESXi с помощью встроенного в таблицу со списком апдейтов поля поиска.

Многошаговый мастер по обновлению хостов ESXi 6.0-6.7 был заменен простым рабочим процессом, в рамках которого процедура remediation требует лишь нескольких кликов:

Также процедура предварительной проверки кластера (pre-check) была вынесена в отдельный рабочий процесс, чтобы не инициировать воркфлоу обновления напрасно.

Между тем, не все рабочие процессы VUM были реализованы - в новой версии этого средства нет обновления VMware Tools и средств проверки совместимости "железа" (hardware compatibility). Но их обещают включить в ближайшем релизе.

Также существенно был ускорен процесс обновления с vSphere 6.5 на vSphere 6.7. Если раньше перед проведением обновления нужно было перезагрузить ESXi, а потом еще и после во второй раз, то теперь само обновление за счет оптимизаций идет быстрее, а перезагрузка требуется всего одна.

Помимо этого, теперь информация об обновлениях более полная и включает в себя критичность апдейта, требуется ли перезагрузка, что именно находится внутри и т.п.

Скачать VMware vSphere 6.7 можно по этой ссылке.

Как вы знаете, совсем недавно компания VMware выпустила обновление платформы виртуализации VMware vSphere 6.7, включая гипервизор ESXi 6.7 и средство управления vCenter Server 6.7. Одной из важных составляющих виртуальной инфраструктуры виртуализации является инфраструктура резервного копирования виртуальных машин. Вряд ли можно себе представить крупную компанию, которая обновляет хосты ESXi 6.0/6.5 на 6.7 и готова остаться без резервного копирования ВМ.

Между тем, с поддержкой новой версии vSphere 6.7, которая вышла 18 апреля, у вендоров решений резервного копирования все весьма плохо. Давайте посмотрим, как именно (об этом рассказал блог tinkertry):

• Altaro VM Backup - на сайте никаких новостей про версию 6.7.
• Commvault - на сайте никаких новостей про версию 6.7.
• Micro Focus VM Explorer Virtual Machine Backup - на сайте никаких новостей про версию 6.7.
• NAKIVO Backup & Replication - на сайте никаких новостей про версию 6.7.
• Unitrends Backup - на сайте никаких новостей про версию 6.7.
• Vembu Backup and Replication - на сайте никаких новостей про версию 6.7.
• Veeam Backup & Replication - на сайте нашлась статья KB 2443, в которой, правда, написано, что vSphere 6.7 пока не поддерживается.

Как мы видим, только Veeam позаботилась о том, чтобы проинформировать своих пользователей о поддержке (а точнее неподдержке) новой версии vSphere 6.7.

При попытке использовать Veeam Backup and Replication 9.5 Update 3 вы получите вот такое сообщение об ошибке:

Error: Object reference not set to an instance of an object

Поэтому придется ждать обновления Update 3a, в котором vSphere 6.7 будет полностью поддерживаться для резервного копирования, репликации и восстановления виртуальных машин. Оно выйдет в самом ближайшем будущем (мы обновим пост).

Update:

1. В блоге Symantec сообщают, что Symantec Backup Exec 20.1 поддерживает последнюю версию vSphere 6.7 (и поддерживал с момента ее выхода).

2. Также в комментариях нам написали, что Veeam Backup and Replication также работает, хотя на форуме Veeam пишут, что бэкап не работает.

Совсем недавно мы писали об утилите Configuration Maximums Tool, которая позволяет сравнить максимумы конфигурации различных версий VMware vSphere. Туда теперь оперативно добавили VMware vSphere 6.7, поэтому давайте посмотрим, как продвинулась новая версия по сравнению с продуктом, который вышел полтора года назад (vSphere 6.5).

В таблице ниже приведены только изменившиеся значения:

Компания VMware, спустя ровно полтора года с момента релиза vSphere 6.5, анонсировала скорую доступность новой версии платформы - VMware vSphere 6.7.

Этот релиз сфокусирован на четырех основных областях улучшений:

• Поддержка увеличивающегося числа и разнообразия приложений.
• Рост объемов использования гибридных облаков.
• Понимание глобального расширения онпремизных датацентров.
• Безопасность инфраструктуры и приложений.

Давайте посмотрим, что нового появилось в VMware vSphere 6.7:

1. Enhanced vCenter Server Appliance (vCSA) и масштабируемая инфраструктура.

Теперь в vCSA есть несколько новых API, которые выводят управление платформой на качественно другой уровень. Кроме того, теперь vCSA поставляется с интегрированными службами embedded platform services controller (обеспечивающими работу служб Single Sign-On), которые могут работать в режиме enhanced linked mode.

Также существенно была увеличена производительность vCSA:

• В 2 раза выросло число операций vCenter в секунду.
• В 3 раза уменьшилось потребление памяти.
• В 3 раза увеличилось число операций DRS (например, включение виртуальной машины и ее первичное размещение в кластере).

2. Улучшения механизма загрузки/перезагрузки хоста ESXi.

Здесь появилось 2 основных улучшения:

• При накате мажорных обновлений теперь требуется не 2 перезагрузки, а одна (Single Reboot).
• Новый механизм vSphere Quick Boot позволяет перезагрузить гипервизор без рестарта всего хоста ESXi.

3. Доработанный HTML5 vSphere Client.

В новом релизе будет обновленная версия клиента для управления vSphere Client на базе технологии HTML5 (добавлены функции управления vSAN и Update Manager), правда пока не понятно, будет ли это полноценная замена vSphere Web Client, или обе версии пока продолжат существовать совместно.

4. Большие улучшения безопасности.

VMware vSphere 6.7 предоставляет поддержку аппаратного модуля Trusted Platform Module (TPM) 2.0, а также появился виртуальный модуль Virtual TPM 2.0. Все это позволяет защититься от атак с подменой хостов и виртуальных машин, а также предотвратить загрузку неавторизованных компонентов.

Также были сделаны улучшения механизма VM Encryption в части рабочих процессов при использовании шифрования. Теперь при миграции виртуальных машин между различными экземплярами vCenter также можно использовать Encrypted vMotion, что расширяет сферу применения данной технологии до гибридных облачных инфраструктур (защищенная горячая миграция в датацентр сервис-провайдера) или инфраструктур с географически разнесенными датацентрами.

Помимо этого, vSphere 6.7 теперь поддерживает технологию Virtualization Based Security, которая используется в гостевых ОС Microsoft Windows.

5. Улучшения поддержки высокопроизводительных приложений.

Как многие из вас знают, поддержка vGPU от NVIDIA и AMD есть в платформе vSphere уже довольно давно. Используется она сейчас не только для виртуальных ПК, но и для таких задач, как системы искусственного интеллекта, machine learning, big data и прочее. Теперь в vSphere 6.7 поддержка такого рода вариантов использования была расширена.

С помощью технологии vSphere Persistent Memory пользователи могут использовать специальные аппаратные модули от Dell-EMC и HPE, которые могут использовать высокопроизводительные системы хранения с большим числом IOPS или предоставлять их возможности гостевым системам как non-volatile memory. Теперь во многих вариантах использования высокопроизводительные приложения смогут работать быстрее.

6. Бесшовная интеграция с гибридной средой.

Теперь в VMware vSphere 6.7 появился режим работы vCenter Server Hybrid Linked Mode, в котором можно соединить две инфраструктуры - вашу онпремизную с одной версией vSphere и облачную, например, VMware Cloud on AWS с другой версией платформы.

Помимо этого, в vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.

Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому в vSphere появилась технология Per-VM EVC (Enhanced vMotion Compatibility), которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.

Также появилась фича поддержки операций cross-vCenter, mixed-version provisioning (таких как vMotion, полное клонирование, холодная миграция), которая позволяет производить эти операции между различными vCenter различных версий (что тоже неизбежно в гибридной среде - вроде связки с vCloud on AWS).

Скачать VMware vSphere 6.7 можно уже сейчас по этой ссылке.

Также обратите внимание на эту страницу, посвященную запуску vSphere 6.7. В ближайшее время мы расскажем о некоторых из описанных функций подробнее.

На днях компания VMware выпустила Configuration Maximums Tool - средство, которое позволяет посмотреть максимумы конфигурации платформ виртуализации, виртуальных машин и других решений VMware в различных категориях. На данный момент поддерживаются версии VMware vSphere 6.0, 6.5 и 6.5 Update 1 (кстати о сравнении максимумов 6.5 и 6.0 мы писали вот тут).

По умолчанию мы видим следующие Configuration Maximums, которые можно сворачивать-разворачивать в пределах категории:

• Virtual Machine Maximums
• ESXi Host Maximums (Compute)
• ESXi Host Maximums (Memory)
• ESXi Host Maximums (Storage)
• ESXi Host Maximums (Networking)
• ESXi Host Maximums (Cluster and Resource Pools)
• ESXi Host Maximums (VMDirectPath)
• vCenter Server Maximums
• vCenter Server Maximums (Storage DRS)
• Platform Services Controller
• vCenter Server Extensions (Update Manager)
• vCenter Server Extensions (vRealize Orchestrator)
• VMware vSphere Flash Read Cache
• VMware vSAN
• Virtual Volumes

Также многим будет интересна фича сравнения максимумов различных версий VMware vSphere:

Сравнить можно 2 или 3 версии платформы, а результат выгрузить в XLS-файл, чтобы использовать его в MS Excel.

VMware Configuration Maximums Tool доступен по этой ссылке: https://configmax.vmware.com/.

Многие администраторы платформы VMware vSphere заметили, что в версии VMware vSphere 6.5 несколько поменялся механизм запуска виртуальных машин в случае сбоя в кластере HA. Об этом интересно недавно написал Дункан Эппинг.

Напомним, что приоритет HA Restart Priority нужен для того, чтобы виртуальные машины могли запуститься в определенном порядке, и их сервисы корректно подхватили уже работающие приложения, запущенные предыдущей очередью ВМ. Всего один хост VMware ESXi может одновременно начать запуск до 32 виртуальных машин, поэтому в большом кластере с большим числом ВМ это действие нужно приоритизировать.

С точки зрения наступления момента запуска следующей очереди набора ВМ есть 4 таких события:

• Resources are allocated - это дефолтная настройка в кластере HA. Ресурсы аллоцируются в тот момент, когда master-хост выбрал хосты для восстановления и запуска ВМ. Это занимает совсем небольшое время (миллисекунды).
• VMs are powered on - это означает, что машина запустилась, и ESXi считает ее запущенной (но не гостевую ОС). Это занимает иногда 10-20 секунд, а иногда и несколько минут.
• Guest heartbeat is detected - это когда от гостевой ОС VMware получает отклик, например, через VMware Tools.
• App heartbeat is detected - это когда получен отклик от определенного приложения. В этом случае у вас должен быть настроен VM/Application Monitoring, который позволит оповестить о том, что приложение запустилось, и можно его использовать.

Если вам нужно убедиться, что работает сервис (то есть гостевая ОС и приложения), так как ВМ следующей очереди должны его использовать - то нужно опираться на последние два события.

Теперь приоритет восстановления ВМ (Restart Priority) содержит 5 уровней вместо трех, которые были в vSphere 6.0:

• Lowest
• Low
• Medium
• High
• Highest

Такие странные названия сделаны в целях совместимости с прошлой классификацией - Low, Medium и High.

Чтобы начать настройку Restart Priority, в vSphere Web Client нужно выбрать кластер HA и перейти на вкладку Configure, после чего выбираем раздел VM Overrides и нажимаем кнопку "Add":

Далее выбираем виртуальные машины, для которых мы хотим задать приоритет запуска:

И здесь главное - это выбор нужного приоритета из пяти уровней и выставление условия "Start next priority VMs when", то есть триггера запуска следующей очереди приоритета:

Все эти настройки применяются и для кластера, в котором не работает vCenter (в случае большого сбоя). Ну и посмотреть текущие настройки приоритетов запуска ВМ в кластере HA можно следующей командой:

/opt/vmware/fdm/fdm/prettyPrint.sh clusterconfig

Вывод будет очень большим, так что ищите в нем текст "restartPriority".

У некоторых пользователей VMware vSphere при обновлении серверов VMware ESXi возникает проблема - при выполнении команды "esxcli software vib update" в ответ возникает ошибка "No space left on device", хотя с дисками все в порядке, и на них много свободного места, в чем можно убедиться с помощью команды df -h.

Например, появляется вот такой вывод при попытке обновления:

[InstallationError]

[Errno 28] No space left on device

vibs = VMware_bootbank_esx-base_6.5.0-1.41.7967591

Please refer to the log file for more details.

В то же время вывод df -h говорит, что места на всех разделах достаточно:

Очень редко причина такого поведения оказывается проста - на хосте не хватает файловых объектов inodes, как описано в KB 1007638. Это объекты файловой системы, которых может быть до 640 тысяч на одном томе VMFS. Их используемое количество зависит от числа файлов в файловой системе в данный момент.

Проверить наличие свободных inodes можно командой stat -f /:

На картинке мы видим, что запас их еще весьма большой - они почти не израсходованы. Как правило, указанного лимита достичь очень и очень сложно, поэтому чаще всего упомянутое выше сообщение об ошибке связано совсем с другим. Но если вы все же достигли этого лимита, решение тут несложное - удалить какое-то число файлов с ESXi.

Например, можно найти лог-файлы и прочие файлы на хосте ESXi размером более 50 МБ, которые находятся НЕ на томах VMFS (чтобы не задеть логи ВМ), можно следующей командой:

find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;

По итогу будет сгенерирован список преимущественно локальных файлов, который будет содержать ISO-образы, большие лог-файлы и т.п., которые уже скорее всего не нужны, и их можно удалить (а лучше переместить на какое-нибудь хранилище в целях архивирования). Также рекомендуем почитать KB 1008643, которая как раз посвящена удалению файлов в целях высвобождения объектов inodes.

Между тем, в случае появления приведенной в начале статьи ошибки о недостатке свободного места очень вероятно, что хост ESXi не может аллоцировать достаточно оперативной памяти (RAM) для проведения обновления. В этом случае вам просто надо включить ESXi system swap, который будет размещен на одном из датасторов, куда будут сбрасываться страницы оперативной памяти при недостатке памяти во время обновления.

Сделать это можно, зайдя в раздел Manage > Settings > System Swap, после чего нажав Edit...:

Выберите датастор и нажмите Ok. Также это можно сделать с помощью функционала Host Profiles:

После выбора датастора для системного свопа обновите хост ESXi и перезагрузите его.

В самом конце прошлого года компания VMware выпустила обновление пакета улучшений гостевых систем VMware Tools 10.2.0. А на днях эта ветка пакета обновилась до версии VMware Tools 10.2.5. Напомним, что ветка тулзов 10.2 - это идейный продолжатель первого ответвления 10.1, которое содержит развивающиеся версии для современных гостевых ОС.

Обновленные VMware Tools совместимы с VMware vSphere 5.5 и более поздними версиями платформы, а также с продуктами для настольной виртуализации VMware Workstation и Fusion.

Давайте посмотрим, что нового появилось в VMware Tools 10.2.5:

• VMware Tools 10.2.5 поддерживает следующие операционные системы:
  • Образ windows.iso поддерживает Windows Vista и более поздние ОС.
  • Образ linux.iso поддерживает Red Hat Enterprise Linux (RHEL) 5 и более поздние, SUSE Linux Enterprise Server (SLES) 11 и позднее, Ubuntu 10.04 и позднее. Также он поддерживает другие дистрибутивы с glibc версии 2.5 и более поздние.
  • Образ darwin.iso поддерживает Mac OS X версии 10.11 и позднее.
  • Образ solaris.iso поддерживает какие может версии Solaris.
• Изменения драйвера NSX: VMware Tools 10.2.5 поддерживают драйвер vnetWFP от Windows 7 и более поздних ОС.
• Возможности Quiesced snapshots - теперь можно исключать некоторые файловые системы из "подмороженных" снапшотов (quiesced snapshots) в гостевых ОС Linux. Эта конфигурация может быть установлена в файле настроек VMware Tools (подробнее написано в документации).
• Настройка отключения display resolution mode: в KB 53572 написано о том, как отключить эту настройку. Чтобы не позволить изменять разрешение экрана через VMware Tools, в VMX-файл виртуальной машины нужно добавить строчку:
  guestInfo.svga.wddm.modeset="FALSE"
  
• Изменения в сетевом драйвере виртуальных сетевых адаптеров виртуальных машин VMXNET3:
  • Функции Receive Side Scaling (RSS) включены по умолчанию.
  • Receive Throttle: дефолтное значение этой настройки установлено в 30.
    Важно отметить, что эти две настройки не обновят существующие сетевые адаптеры. Новые настройки будут применены только к свеженакатанным VMware Tools или при добавлении новых адаптеров к ВМ. Для обновления существующих адаптеров используйте скрипт. Более подробно об этом рассказано в KB 2008925.

Загрузить VMware Tools 10.2.5 можно по этой ссылке. Release notes доступны тут, а полный набор документации - тут.

Компания VMware на днях выкатила пачку новостей об обновлении основных продуктов для виртуальных датацентров и облачных сред, среди которых нужно отметить анонс обновления решения для автоматизации операций VMware vRealize Operations 6.7, которое выйдет в ближайшем будущем. Напомним, что о прошлом обновлении vRealize Operations Manager 6.6 (части пакета Operations) мы писали летом прошлого года. Решение vRealize Operations включает в себя 3 основных компонента:

• VMware vRealize Operations Manager
• VMware vRealize Configuration Manager
• VMware vRealize Hyperic

Новая версия vRealize Operations 6.7 (vROPs) сфокусирована на возможностях "self-driving", то есть вы будете определять цель оптимизаций, а движок будет в постоянном режиме генерировать рекомендации по их достижению и выполнять операции по автоматизации.

Давайте посмотрим, что это за возможности:

1. Улучшенный пользовательский интерфейс.

Интерфейс стал проще, четче, появилась персонализированная панель Quick Start, а также обновилась визуализация большинства workflow:

2. Автоматизация на базе поставленных целей.

Первым шагом нужно получить текущее состояние датацентра:

Затем надо задать целевые настройки, такие как целевое использование ресурсов в кластере, их уровень загрузки и параметры размещения виртуальных машин на основе их тэгирования:

• Уровни SLA: Gold, Silver Bronze
• Лицензионные политики: Windows, Oracle, Linux
• Вид комплаенса: PCI, HIPAA
• Политики размещения приложений в ВМ (вместе/отдельно на хостах)

После того, как цели определены, можно начинать операции по их достижению в разрезе производительности кластера и его конфигураций. Эти действия могут быть исполнены тремя способами:

• Немедленное выполнение на базе выданных рекомендаций (в ручном режиме).
• Запланированные действия в рамках мероприятий по оптимизации датацентра.
• Исполнение действий в случае, если случится проблема с производительностью, и не будут исполняться изначально заданные рамки метрик.

3. Оценка емкости датацентра, затрат и экономии и автоматизация оптимизации.

Умные дэшборды могут указать, какие изменения можно произвести в датацентре (удалить машины и хранилища, реорганизовать использование лицензий), чтобы сэкономить деньги, которые тратятся ежемесячно:

После расчета потенциальной экономии можно приступать к действиям по оптимизации. Можно консолидировать машины поплотнее и высвободить хосты ESXi, либо целью консолидации может быть, например, использование меньшего числа лицензий, если они привязываются к физическому оборудованию:

4. Предсказание увеличенной нагрузки и дефицита ресурсов, а также получение рекомендаций.

Новый движок по аналитике емкости датацентра позволяет:

• Посмотреть исторические данные о нагрузке CPU, памяти и диска и сделать вывод о росте или падении нагрузки.
• Получить рекомендации о том, нужно ли добавить ресурсы и сколько, либо, наоборот, вывести лишние ESXi из кластера.

5. Моделирование сценариев "что-если".

Теперь можно моделировать различные сценарии для рабочих нагрузок и получать стоимость их эксплуатации и срок, до которого все будет работать в заданном коридоре производительности. Делать это можно как для частного, так и для гибридного/публичного облака VMware Cloud on Amazon AWS.

6. Интеграция с решением VMware Wavefront.

Теперь в vROPS появилась интеграция с продуктом для отслеживания производительности приложений VMware Wavefront. Теперь vROPs может отправлять данные о конфигурация и метриках напрямую в Wavefront, что позволит добиться оптимизаций на уровне приложений в виртуальных машинах.

Заявлено, что VMware vRealize Operations 6.7 выйдет до 4 мая 2018 года.

В ноябре прошлого года компания VMware выпустила VMware ESXi Embedded Host Client версии 1.24. На днях вышло очередное обновление, которое перепрыгнуло через 5 минорных версий - Host Client 1.29.

Давайте посмотрим, что нового появилось в функциональности Host Client за почти полгода:

• Пофикшен баг с очисткой выделения области при удалении виртуальной машины.
• Исправлена ошибка с мастером хранилищ для очень больших датасторов.
• Обновление списка доступных RDM-дисков в списке создания виртуальной машины.
• Исправлена ошибка с неправильным отображением размера датастора в мастере.
• Улучшена поддержка сетей решения NSX.
• Пофикшены проблемы с переходом в полноэкранный режим и открытием новой вкладки консоли.
• Опциональное поле на странице логина теперь не заполняется менеджерами паролей браузеров.
• Небольшие исправления ошибок и косметические изменения.

Согласитесь, практически никакое обновление для версии, которую ждали больше 5 месяцев. Ну что делать, все равно обновиться не помешает, скачать VMware ESXi Embedded Host Client 1.29 можно по этой ссылке.

Если вы счастливый обладатель коммутаторов Cisco, то функция Get-VMHostCDP выдаст вам всю необходимую информацию о настройках сети с помощью протокола CDP (Cisco Discovery Protocol). Также информацию, предоставляемую CDP протоколом для одного сетевого адаптера ESXi хоста, можно получить в GUI...

Недавно мы писали о полезном документе для администраторов VMware vSphere 6.5 - Performance Best Practices for VMware vSphere 6.5. Этот документ обязательно надо прочитать, там много всего полезного и интересного.

Например, там есть немного про улучшение команды esxtop, показывающей производительность хоста и виртуальных машин в различных аспектах. Теперь там добавилась метрика Power Management, где можно в реальном времени наблюдать за актуальной частотой процессора. Эта информация теперь отображается в колонке %A/MPERF.

Чтобы добавить ее, после запуска esxtop нажмите клавишу <p> и затем клавишу <f> для добавления колонки.

Вы увидите значения, некоторые из которых больше 100. Например, для процессора 2 и 4 на картинке выше значения равны 150. При этом это процессор Xeon E5-2699 v3 2.3 ГГц с функцией разгона частоты Turbo Boost до 3.6 ГГц. Значение 150 означает, что в данный момент процессор работает на частоте 2.3*1.5 = 3.45 ГГц, то есть почти на пределе.

Продолжаем информировать вас о выпусках обновлений и заплаток уязвимостей Meltdown и Spectre для виртуальной инфраструктуры VMware vSphere. Напомним наши прошлые посты:

• Как отслеживать производительность хостов VMware ESXi после патчей Meltdown и Spectre с помощью VMware vSphere Operations Manager
• Вышел VMware vCenter Server Appliance 6.5 Update 1f - исправлена уязвимость Meltdown и Spectre (частично)
• Производительность хост-серверов VMware ESXi и других платформ после наката патчей для Meltdown и Spectre
• Для VMware vSphere, Workstation и Fusion пофикшена уязвимость Spectre
• Скрипт для проверки виртуальной инфраструктуры VMware vSphere на подверженность уязвимости Spectre

На днях наш читатель Стас прислал новость о том, что VMware выпустила обновления, закрывающие уязвимость Spectre, на этот раз для ключевых компонентов виртуальной инфраструктуры - серверов vCenter и ESXi. Таким образом, согласно VMware Security Advisory VMSA-2018-0004.3, теперь от уязвимости Spectre защищены все основные продукты VMware трех последних поколений:

Начнем с обновлений для vCenter. Тут были выпущены следующие апдейты:

• VMware vCenter Server 5.5 Update 3h (Release notes, скачать)
• VMware vCenter Server 6.0 Update 3e (Release notes, скачать)
• VMware vCenter Server 6.5 Update 1g (Release notes, скачать)

Для серверов VMware ESXi были выпущены следующие патчи:

• ESXi550-201803001 (ESXi550-201803401-BG и ESXi550-201803402-BG)

• ESXi600-201803001 (ESXi600-201803401-BG и ESXi600-201803402-BG)

• ESXi650-201803001 (ESXi650-201803401-BG и ESXi650-201803402-BG)

Чтобы скачать эти обновления для ESXi, нужно пойти VMware Patch Portal и поискать там обновления для соответствующей версии ESXi.

Кроме наката патчей гипервизора VMware ESXi, вам также придется обновить микрокод серверов. Более подробная информация об этом приведена в KB 52085.

Помните, что порядок наката обновлений безопасности таков:

1. Накатываем обновления vCenter.

2. Обновляем ПО гипервизора на серверах VMware ESXi - накатываем апдейты, заканчивающиеся на 01-BG (позволяет гостевым ОС использовать новый механизм speculative-execution control), одновременно с этим обновляем и микрокод серверов (апдейты, заканчивающиеся на 02-BG), которое применяется в процессе загрузки ESXi. Оба патча накатываются в рамках одного профиля.

На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).

Выключение кластера vSAN

1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):

2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):

Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.

3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:

На этом скриншоте видно, что никаких процессов ресинхронизации сейчас не идет. Если они у вас есть, то следует дождаться их завершения.

4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):

В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):

5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:

После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:

6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:

Аналогично укажите, что не нужно переносить данные кластера vSAN:

Также это можно сделать следующей командой esxcli в консоли сервера:

# esxcli system maintenanceMode set -e true -m noAction

Включение кластера VMware vSAN

1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:

Сделать это также можно командой esxcli:

# esxcli system maintenanceMode set -e false

2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:

3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:

4. Только после этого включаем все виртуальные машины:

Многие из вас иногда хотят получить так называемый "Support Bundle", содержащий лог-файлы, диагностическую информацию и метрики производительности, который помогает решать проблемы в инфраструктуры VMware vSphere. В первую очередь, этот бандл нужен для предоставления службе технической поддержки VMware GSS (Global Support Services) информации о конфигурации виртуальной среды, чтобы она могла решать возникающие у клиентов проблемы в рамках обращений (тикетов) в техподдержку.

Но, кроме этого, данный бандл может пригодиться и вам, как, например, описано в этой статье для анализа причин "розового экрана смерти" и прочих аномалий.

Давайте рассмотрим основные способы получения support bundle как для серверов VMware vCenter (для Windows или виртуального модуля vCenter Server Appliance, vCSA), так и для серверов VMware ESXi. Кстати, надо учитывать, что после экспорта бандла с логами результирующий файл будет размером 30-300 МБ в зависимости от того, что вы туда включите, а также как давно и интенсивно менялась конфигурация виртуальной среды.

Получение Support Bundle для серверов vCenter

Самый простой способ получить саппорт бандл - это выгрузить его с помощью vSphere Web Client. Для этого нужно выбрать сервер vCenter в иерархии инвентори и выбрать пункт Export System Logs (работает как для обычного vCenter, так и для vCSA):

Далее вам предложат, какие разделы нужно включить в сгенерированный бандл логов:

Если вы используете vCSA, то можно получить логи через веб-интерфейс. Для этого надо перейти по адресу:

https://<ip vcsa>/appliance/support-bundle

И далее ввести логин и пароль root от виртуального модуля vCSA.

После этого support bundle будет сгенерирован и загружен через ваш браузер.

Кроме этого, есть способ получить логи vCSA из Linux-системы с помощью утилиты curl. Для этого нужно выполнить следующую команду:

curl -k -u root -o support-bundle.tar.gz -O https://<ip vcsa>/applmgmt/support-bundle

После того, как вы скачаете этот бандл, нужно будет разархивировать его командой:

tar -zxvf support-bundle.tar.gz

Также Support Bundle можно получить с помощью PowerCLI. Для этого нужно соединиться с сервером vCenter:

Connect-VIServer -Server HostnameOrIPAddress

И далее использовать следующую команду:

Get-Log -Bundle -DestinationPath c:\Storage\Location\

Более подробная информация об этом приведена в KB 1027932. Там же, кстати, есть информация и о том, как искать в файлах логов с помощью PowerCLI:

Get-VMHost HostNameOrIP | Get-Log LogName | Select -expand Entries | Select-String SearchTerm | More

Здесь SearchTerm - это строка поиска, а LogName - это один из следующих логов:

• hostd
• vpxa
• messages
• vmkernel
• vmksummary
• vmkwarning

Получение Support Bundle для серверов ESXi

По аналогии с получением бандла для сервера VMware vCenter или vCSA, в vSphere Client можно выбрать сервер VMware ESXi и выбрать для него пункт "Export System Logs":

Также можно сгенерировать Support Bundle через тонкий клиент для управления серверами VMware ESXi - Embedded Host Client (он же - просто веб-интерфейс для управления хостами ESXi). Он доступен при соединении с хостом ESXi по ссылке:

https://<ip esxi>/ui

Для генерации саппорт бандла нужно выбрать пункт "Generate support bundle" из контекстного меню хоста:

Помимо этого, его можно сгенерировать и в консоли ESXi. Для этого используется команда vm-support без параметров (подробнее об этом написано в KB 1010705). Чтобы получить Support Bundle нужно в консоли ESXi выполнить следующую команду:

# vm-support

Надо отметить, что у утилиты есть множество разных параметров:

Аналогично получению бандла для vCenter, через PowerCLI можно получить и бандл для хоста ESXi. Соединяемся с хостом, забираем бандл и складываем его в нужную папку:

Get-VMHost HostNameOrIP | Get-Log -Bundle -DestinationPath c:\Storage\Location\

Для тех, кто хочет узнать, что же находится внутри Support Bundle, мы рекомендуем статью "What's Inside an ESXi vm-support Bundle?".